@IonutIT

I re edit my post above.
kea2unbound is innocent 👍
The issue is deep in the GUI, and identical to my initial pfBlockerng issue.

I'll have a patch some where next week.

@JonathanLee I block DNS over HTTPS to the firewall using unbound because I have unbound running DoT. My solution to the Nintendo griping about DNS was to route it out to 1.0.0.2. I was also having issues with unbound using the ephemeral ports I was using, interrupting my sensitive codel games so had change localhost's NAT outbound.

@stephenw10 yes we can agree the user can configure it wrong all over. Again, an administrator might fat finger a large static DHCP list with a couple entries thus causing hostname mix ups. That for one would be very hard to pinpoint. Moreover, we know the amount of hours system administrators work. It's a lot of hours. This would make PfSense have a ease of use software functionality built in. I assumed that if pfSense allowed multiple duplicate entries, it was done for a situation when two devices need to be swapped in and out and need the same IP address, in this mindset PfSense should still log the correct hostnames. Again, if that was the reason for PfSense allowing the GUI duplicate entries.

Weird thing to research, but the hostnames mixup was what I was after and or why
PfSense would allow the duplicate entries in the first place. Let's agree admins have monster static dhcp lists that are updated and changed all the time within a secure setting. This situation would want controls in place for hostnames. Finally, logs for the hostnames could get bonkered up and with a monster list and that would be hard to track down why hostnames are wrong. We know PfSense now has experimental layer 2 Ethernet filtering.

@werter вообще-то упомянул, но не суть. В принципе тему можно закрывать, я нашел выход насчет арп записей и статических маршрутов. Просто добавить основной маршрутизатор в арп

@gertjan said in DHCP static mappings that don’t specify hostnames:

@bp81 said in DHCP static mappings that don’t specify hostnames:

I am observing that any client that has a static mapping set but has the hostname field blank in the mapping does not get registered in dns. Non static clients will get registered as expected.

Ask pfSense what it is doing, and it will tell us :

/usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid interface1 interface2 .....

The DHCP server config file /var/dhcpd/etc/dhcpd.conf shows me how known static leases are setup for the dhcpd process.
I guess, when creating a static based MAC lease, the info is used to create a /var/dhcpd/etc/dhcpd.conf so dhcpd knows about it, and at the same time a line is added to /etc/hosts.
/etc/hosts is read by unbound when it starts executing.

Take a look at the /var/dhcpd/var/db/dhcpd.leases file.
You will find some leases like :

lease 192.168.1.71 { starts 4 2022/07/21 09:10:02; ends 5 2022/07/22 09:10:02; cltt 4 2022/07/21 11:47:01; binding state active; next binding state free; rewind binding state free; hardware ethernet 18:e7:b0:cc:bc:d9; uid "\001\030\345\260\039\005\341"; client-hostname "iPhone-12-Jullien"; }

and other leases do not have a client-hostname at all.
Or worse, do have a client-hostname, but this name is not DNS-hostname format compatible.
Understand that the client-hostname is given to the dhcpd server by the device, using it's dhcp client. The client-hostname can be setup by the person who admins the device. If the device even has this capability. Many device have a client-hostname hard coded, or omit it.

My /var/dhcpd/var/db/dhcpd.leases file contains 276 leases, and only 12 have a client-hostname given by a device.

So : using the client-hostname given by the client is ..... not a safe solution.

@bp81 said in DHCP static mappings that don’t specify hostnames:

I am observing that any client that has a static mapping set but has the hostname field blank

There was a forum thread a while ago about this question.
Or was it : give MAC and hostname but no IPv4 in a static .... ? Don't recall.

Consider the "DNS" as a phone book.
One rule, no exception. Planet earth goes down ? Still no exceptions.
The rule is :
Phone number <=> Name.
If one of the two is missing the system goes belly up.
DNS down is bad for business (but a very popular amusement, see the forum, it''s an on going occupation for many)

So, I guess pfSense want you (forces you) to give a host name. That's the name that can be checked against DNS name compliance. That's the one being used in for DNS.

You can change this behaviour of course, no need to inform the dhcpd process with a setting. It's all 'pfSense GUI' scripted somewhere in the PHP files.

But take note : if you decide to add some script logic that uses the "client-hostname" (the name given by the client) then you need some other process that parses the /var/dhcpd/var/db/dhcpd.leases and now you have opened a can of worms. Just read the several thouands of forum post about this process :

[/usr/local/sbin/dhcpleases -c /usr/local/bin/php-cgi -f /usr/local/sbin/prefixes.php -l /var/dhcpd/var/db/dhcpd.leases

This process is activated when you select this option :
cd729aba-4fc9-4b9c-af35-d7bc5b3c9d92-image.png

This process stops and unbound (your local DNS !) every time a DHCP lease comes in, or gets renewed.

Now you know why I strongly advice to disable this option :

7db176b8-31f7-4071-9d1b-529db9fa7fd7-image.png

for every device that you have to know by hostname, pick an easy DNS hostname, and make a static MAC lease.
I know this isn't the perfect solution, but it's the one that works, is easy to maintain, and unbound will restart far less often, so DNS keeps on working, and the cache gets build and stays valid.

This one :

a26ab38c-7ba1-4263-8bb0-5a5f9e192d9a-image.png

is 'harmless' as /etc/hosts only gets read when unbound starts.

In short, it appears it is not possible to create the behavior I'm looking for. It's not terribly important to us, it just would've been nice.

The background on our infrastructure is that we have a mixed environment administered by Active Directory and Windows DNS. We have Windows workstations, laptops, and servers, but we also have some Linux and FreeBSD systems, as well as some IoT devices. Hostname resolution of Windows machines in Windows DNS is easy; Active Directory joined workstations have a group policy set to register their hostnames in Windows DNS.

To get non-Windows systems registered in DNS, we are using some scripting to read the dhcp leases file and dhcp config file from dhcpd, then doing some filtering to determine which leases belong to non-Windows devices and dynamically register those in Windows DNS. This is being done with a powershell script. The end result being that we now have resolution by hostname for every single device provisioned by DHCP in our network (and that is ALL devices at this point. We don't do manual IP address assignment on any system at this point). The scripting based solution works very nicely, it just would've been nice if we had the option to assign an IP address via DHCP static reservation without having to assign a hostname in the static reservation. That creates a condition where, when I create static reservations, I have to remember to leave the hostname field blank for Windows machines (which will register their DNS hostnames directly with AD DNS) but specify hostnames in the reservations for non-Windows systems.

It's not really that big of a deal, it would just be more convenient to be able to write my DHCP reservations in a consistent manner for all entries rather than having one kind of entry for Windows systems and a different kind of entry for non-Windows systems.

Assume for the moment that the error message is actually correct. Check all the existing DHCP Lease information to see if that IP address, MAC, or hostname was already assigned. DHCP can hold inactive lease information for a while.

Also check Diagnostics->ARP Table, to see if that IP address is already listed to a different MAC address. It's possible that the address was used in a local static assignment already, not involving DHCP. You should do this shortly after trying to assign the static mapping as ARP entries will expire from the cache. Note: if DHCP relaying is involved you'll need to check this on a box attached to the subnet in question, using "arp -a" (works on *nix and Windows).

Originally I thought that it could have been you were trying to make permanent the IP address it got dynamically from the DHCP Pool, but that yields a very specific error message to that effect. At least in version 2.4.3.